1. Field of the Invention
This invention pertains to the processing of computer networks, networking equipment, and networking protocols, and in particular to systems that enhance the performance of existing networking applications through the deployment of additional networking entities.
2. Background of the Invention
Many computer networking technologies and protocols are well known. One of the most widely used protocols is the Internet protocol (IP). IP is a connectionless, best-effort, unreliable, routable networking protocol. Applications that require reliable communications typically use the Transmission Control Protocol (TCP) on top of IP. The TCP protocol layer provides required functionality such as flow control, packet loss detection, lost packet retransmission, congestion avoidance, etc. (hereinafter referred to as upper-layer behaviors) that are needed to provide reliable communications over the unreliable IP networking substrate. This pair of networking protocols is common enough that they are often referred to jointly as TCP/IP. Detailed descriptions of TCP and IP are found in RFC 792 and RFC 793.
Research has developed a simple model that predicts the maximum performance of TCP implementations that use the standard congestion avoidance algorithm (TCP Reno and TCP Tahoe). One good explanation of this model and its derivation is in a paper by Matthew Mathis, Jeffrey Semke, and Jamashid Mahdavi, entitled “The Macroscopic Behavior of TCP Congestion Avoidance Algorithm.” Equation 3 of the paper provides a simple model of TCP performance:BW=(MSS*C)/(RTT*SQRT(P))where:                BW=Bandwidth for the TCP Connection        MSS=Maximum Segment Size, i.e., the size of the packets being transported        RTT=Round Trip Time        P=Percentage of packet loss in the network        C=A constantOne of the surprising results of this model is that maximum TCP performance is unrelated to network speed. Another surprising result is that maximum performance is inversely related to round trip time (RTT).        
Other phenomena may limit performance below what the model provides as a maximum. For example, if the receiver does not advertise a window that is at least as large as the bandwidth delay product of the connection, then maximum TCP performance will be limited accordingly. Standard implementations of TCP are also known to perform poorly in certain environments and/or conditions. For example, the high rate of packet loss in typical wireless links results in poor TCP performance.
One method of correcting many of these problems is to modify the TCP implementation of one or both of the participants. However, this is frequently not a viable option such as when the source code is unavailable or when there are too many endpoints to manage conveniently.
Another method is to interpose another element in the TCP conversation. This element, called a Performance Enhancing Proxy (PEP), applies algorithms to manipulate the conversation so as to overcome the performance limitations. There are types of conventional PEPs and PEP algorithms are known, as described for example in RFC 3135.
Deployment of conventional PEPs in a network is known by providing a new network processing node and routing packets through it. This technique suffers from at least two disadvantages: first, the extra expense of the additional processing node and its associated administrative overhead; and second, the conventional PEP often requires redundant processing due to the poor integration with the other nodes of the network.
Another method of deploying a conventional PEP is to insert it into the software driver stack of a node. Many operating systems provide the ability to insert a software agent (shim) between the TCP/IP processing stack and the driver for the network interface card (NIC). One advantage of this method is that no changes to the operating system are required, which, in any event, may be impossible since access to the source code is frequently limited. Even with access to the source code of an operating system, the operational issues associated with supplying and supporting customized versions of the operating system make this prohibitive in many environments.
Conventional PEPs have a number of shortcomings, including the need for substantial network changes, utility and application changes, administrative overhead, and extensive use of system and network resources. It would be desirable for the addition of PEPs (either in shim or stand-alone form) be done in such a way as to minimize changes required to other nodes of the network. In particular, no changes should be required to existing utilities and application programs. No changes to firewall settings, routing tables, or port assignments should be required. No retraining of users or network operations staff should be required. No re-installation of applications or utilities should be required. New software that is being developed should be able to take advantage of PEP capabilities without any change to the development process or to the software itself.
Ideally, existing network equipment and software, both on the Local Area Network (LAN) and the Wide Area Network (WAN), should require minimal, if any, modification. It would also be desirable for the PEP itself should not require substantial system resources, such as random access memory or disk storage. Requiring large amounts of these resources not only increases system expense, but also requires additional environment attention (more power, more space, etc.) and also reduces overall system reliability.
Likewise, it would be desirable for communications protocols used by the PEP to adhere to the standard TCP/IP protocols as they currently appear on the network, minimizing any disruption to existing network software or equipment and ensuring compatibility with new equipment that is currently in development now or in the future by inventors not aware of the present invention. Some prior art techniques translate the TCP/IP protocol into other protocols (e.g., User Datagram Protocol (UDP)), causing disruption to network monitoring, traffic shaping, Quality of Service (QoS), Service Level Agreement (SLA), statistics measuring applications, and others; they also require modifications to firewall and security settings due to the usage of protocols that were not previously employed. Worse, applications environments and settings will require modification to direct traffic flows to explicitly designated transcoding network nodes.
Security techniques that are currently deployed should be preserved wherever possible. It would be desirable for the PEP to be fully functional in the presence of modern encryption and authentication techniques. Moreover, the PEP should operate incrementally, with a minimal increase in the latency of data transmission. It should not require access to multiple blocks of data before data transmission can begin. It would also be desirable to minimize a latency of data transiting a PEP.
Similarly, it would be desirable to have algorithms employed by a PEP not be subject to any arbitrary limits. They should scale to any arbitrary speed and handle any type of connection media, including high-delay satellite links, high loss-rate wireless and power-line networking links, and others. The algorithms should function properly in the presence of standard traffic management techniques. Plus, it should smoothly operate with any existing Quality of Service (QoS) or service level agreement (SLA) architecture that might be deployed, allowing these systems to limit the performance of the original endpoint, just as though the PEP were not present.
TCP connection characteristics can be measured along multiple dimensions. A partial list of the dimensions includes: RTT, connection bandwidth, aggregate loss rate, connection lifetime, application burstiness, and others. Across all of these dimensions, no algorithm can be optimal. A PEP should monitor the connection, characterizing it as conditions change, adapting the PEP algorithms accordingly.
One example of prior art is the Transporter Fountain from Digital Fountain Corporation of Fremont, Calif. The product is intended to transfer files across large RTT links without the performance limits that standard File Transfer Protocol-based (FTP) techniques suffer from. (FTP uses TCP/IP that has the performance limit described above.) This product consists of a “box” that the user connects to his network. The user must explicitly copy the files to be transferred to the box before the files can be transferred. Thus, all applications programs and scripts that wish to utilize the product must be changed to utilize the new box with its proprietary command set. Further, the transfer protocols used by the product are UDP based, requiring the modification of network settings, such as security, QoS, SLA, traffic management, and others. The transcoding from FTP to UDP interferes with any network element that might attempt to process the individual TCP connection, such as QoS, SLA or traffic management.
Another example of prior art is the Sequence Reducer from Peribit Corporation of Santa Clara, Calif. This product provides data compression using advanced data sequence recognition techniques developed for the Human Genome project. However, general-purpose lossless data compression is typically limited to a two- to three-times reduction in data, placing an upper limit on the total performance improvement that can be provided by this technique. Further, many data types are already compressed, wasting system resources attempting any further compression for these data types. The computational expense of this method requires the addition of an extra box to the network and limits the speed at which packets can be processed. Current CPU technology seems to limit processing speeds to about 45 Mb/sec (T3) for any one connection. Current data link speeds are well in excess of this limit and growing at a faster rate than CPU performance is growing. The product does not address the fundamental limits of the TCP/IP protocol and is thereby permanently limited to a maximum of two- to three-times performance improvement over offerings without the PEP.
Research into methods of improving the performance limit of TCP is on-going. One proposal, MulTCP, is documented in the paper “Differentiated End-to-End Internet Services using a Weighted Proportional Fair Sharing TCP” by John Crowcroft and Philippe Oechslin.
Consequently, a new system and/or method of creating and deploying of PEPs is required to efficiently integrate them into a network. These PEPs would preferably supply algorithms that remove the performance limitations inherent in TCP implementations.